Python Data Warehousing: Eine umfassende Anleitung zum OLAP-Systemdesign

In der heutigen datengesteuerten Welt ist die Fähigkeit, riesige Informationsmengen schnell zu analysieren, nicht nur ein Wettbewerbsvorteil, sondern eine Notwendigkeit. Unternehmen auf der ganzen Welt verlassen sich auf robuste Analysen, um Markttrends zu verstehen, Abläufe zu optimieren und strategische Entscheidungen zu treffen. Im Mittelpunkt dieser analytischen Fähigkeit stehen zwei grundlegende Konzepte: das Data Warehouse (DWH) und Online Analytical Processing (OLAP)-Systeme.

Traditionell erforderte der Aufbau dieser Systeme spezialisierte, oft proprietäre und teure Software. Der Aufstieg von Open-Source-Technologien hat jedoch das Data Engineering demokratisiert. An vorderster Front steht Python, eine vielseitige und leistungsstarke Sprache mit einem reichhaltigen Ökosystem, die sie zu einer außergewöhnlichen Wahl für den Aufbau von End-to-End-Datenlösungen macht. Diese Anleitung bietet einen umfassenden Überblick über den Entwurf und die Implementierung von Data-Warehousing- und OLAP-Systemen mit dem Python-Stack, zugeschnitten auf ein globales Publikum von Dateningenieuren, Architekten und Entwicklern.

Teil 1: Die Eckpfeiler der Business Intelligence - DWH und OLAP

Bevor wir uns mit Python-Code beschäftigen, ist es wichtig, die architektonischen Prinzipien zu verstehen. Ein häufiger Fehler ist der Versuch, Analysen direkt auf operativen Datenbanken durchzuführen, was zu schlechter Leistung und ungenauen Erkenntnissen führen kann. Dies ist das Problem, das Data Warehouses und OLAP lösen sollen.

Was ist ein Data Warehouse (DWH)?

Ein Data Warehouse ist ein zentrales Repository, das integrierte Daten aus einer oder mehreren unterschiedlichen Quellen speichert. Sein Hauptzweck ist die Unterstützung von Business-Intelligence-(BI-)Aktivitäten, insbesondere Analysen und Berichterstattung. Stellen Sie es sich als die einzige Quelle der Wahrheit für die historischen Daten einer Organisation vor.

Es steht in starkem Kontrast zu einer Online Transaction Processing (OLTP)-Datenbank, die alltägliche Anwendungen unterstützt (z. B. ein E-Commerce-Checkout-System oder das Transaktionsregister einer Bank). Hier ist ein kurzer Vergleich:

• Workload: OLTP-Systeme verarbeiten eine große Anzahl kleiner, schneller Transaktionen (Lesen, Einfügen, Aktualisieren). DWHs sind für eine kleinere Anzahl komplexer, langlaufender Abfragen optimiert, die Millionen von Datensätzen scannen (leselastig).
• Datenstruktur: OLTP-Datenbanken sind stark normalisiert, um die Datenintegrität zu gewährleisten und Redundanz zu vermeiden. DWHs sind oft denormalisiert, um analytische Abfragen zu vereinfachen und zu beschleunigen.
• Zweck: OLTP dient der Ausführung des Geschäfts. DWH dient der Analyse des Geschäfts.

Ein gut konzipiertes DWH zeichnet sich durch vier Schlüsseleigenschaften aus, die oft dem Pionier Bill Inmon zugeschrieben werden:

• Subject-Oriented: Die Daten sind um die wichtigsten Themen des Geschäfts herum organisiert, wie "Kunde", "Produkt" oder "Umsatz", und nicht um Anwendungsprozesse.
• Integrated: Die Daten werden aus verschiedenen Quellen gesammelt und in ein einheitliches Format integriert. Beispielsweise könnten "USA", "Vereinigte Staaten" und "U.S." alle auf einen einzigen Eintrag "Vereinigte Staaten" standardisiert werden.
• Time-Variant: Die Daten im Warehouse stellen Informationen über einen langen Zeitraum dar (z. B. 5-10 Jahre), was historische Analysen und die Identifizierung von Trends ermöglicht.
• Non-Volatile: Sobald Daten in das Warehouse geladen wurden, werden sie selten bis nie aktualisiert oder gelöscht. Sie werden zu einer permanenten Aufzeichnung historischer Ereignisse.

Was ist OLAP (Online Analytical Processing)?

Wenn das DWH die Bibliothek historischer Daten ist, dann ist OLAP die leistungsstarke Suchmaschine und das Analysewerkzeug, mit dem Sie sie erkunden können. OLAP ist eine Kategorie von Softwaretechnologie, die es Benutzern ermöglicht, Informationen schnell zu analysieren, die in mehrdimensionale Ansichten zusammengefasst wurden, die als OLAP-Cubes bekannt sind.

Der OLAP-Cube ist das konzeptionelle Herzstück von OLAP. Er ist nicht unbedingt eine physische Datenstruktur, sondern eine Möglichkeit, Daten zu modellieren und zu visualisieren. Ein Cube besteht aus:

• Measures: Dies sind die quantitativen, numerischen Datenpunkte, die Sie analysieren möchten, wie z. B. "Umsatz", "Verkaufte Menge" oder "Gewinn".
• Dimensions: Dies sind die kategorialen Attribute, die die Measures beschreiben und Kontext liefern. Gängige Dimensionen sind "Zeit" (Jahr, Quartal, Monat), "Geografie" (Land, Region, Stadt) und "Produkt" (Kategorie, Marke, Artikelnummer).

Stellen Sie sich einen Cube mit Verkaufsdaten vor. Sie könnten den Gesamtumsatz (die Measure) über verschiedene Dimensionen hinweg betrachten. Mit OLAP können Sie mit unglaublicher Geschwindigkeit leistungsstarke Operationen auf diesem Cube durchführen:

• Slice: Reduzierung der Dimensionalität des Cube durch Auswahl eines einzelnen Werts für eine Dimension. Beispiel: Anzeige der Verkaufsdaten nur für 'Q4 2023'.
• Dice: Auswahl eines Sub-Cube durch Angabe eines Wertebereichs für mehrere Dimensionen. Beispiel: Anzeige der Verkäufe für 'Elektronik' und 'Bekleidung' (Produktdimension) in 'Europa' und 'Asien' (Geografiedimension).
• Drill-Down / Drill-Up: Navigation durch Detailebenen innerhalb einer Dimension. Drill-Down bewegt sich von Zusammenfassungen auf höherer Ebene zu Details auf niedrigerer Ebene (z. B. von 'Jahr' zu 'Quartal' zu 'Monat'). Drill-Up (oder Roll-Up) ist das Gegenteil.
• Pivot: Drehen der Achsen des Cube, um eine neue Ansicht der Daten zu erhalten. Beispiel: Vertauschen der Achsen 'Produkt' und 'Geografie', um zu sehen, welche Regionen welche Produkte kaufen, anstatt welche Produkte in welchen Regionen verkauft werden.

Arten von OLAP-Systemen

Es gibt drei Hauptarchitekturmodelle für OLAP-Systeme:

1. MOLAP (Multidimensional OLAP): Dies ist das "klassische" Cube-Modell. Die Daten werden aus dem DWH extrahiert und in einer proprietären, multidimensionalen Datenbank voraggregiert. Vorteile: Extrem schnelle Abfrageleistung, da alle Antworten vorab berechnet werden. Nachteile: Kann zu einer "Datenexplosion" führen, da die Anzahl der voraggregierten Zellen enorm werden kann, und es kann weniger flexibel sein, wenn Sie eine Frage stellen müssen, die nicht vorhergesehen wurde.
2. ROLAP (Relational OLAP): Dieses Modell speichert die Daten in einer relationalen Datenbank (typischerweise dem DWH selbst) und verwendet eine ausgefeilte Metadatenschicht, um OLAP-Abfragen in Standard-SQL zu übersetzen. Vorteile: Hochgradig skalierbar, da es die Leistungsfähigkeit moderner relationaler Datenbanken nutzt und detailliertere Echtzeitdaten abfragen kann. Nachteile: Die Abfrageleistung kann langsamer sein als bei MOLAP, da Aggregationen on the fly durchgeführt werden.
3. HOLAP (Hybrid OLAP): Dieser Ansatz versucht, das Beste aus beiden Welten zu vereinen. Er speichert hochaggregierte Daten in einem MOLAP-ähnlichen Cube für Geschwindigkeit und speichert detaillierte Daten in der relationalen ROLAP-Datenbank für Drill-Down-Analysen.

Für moderne Datenstacks, die mit Python erstellt wurden, sind die Grenzen verschwommen. Mit dem Aufstieg unglaublich schneller spaltenorientierter Datenbanken ist das ROLAP-Modell dominant und hocheffektiv geworden und bietet oft eine Leistung, die mit traditionellen MOLAP-Systemen mithalten kann, ohne die Starrheit.

Teil 2: Das Python-Ökosystem für Data Warehousing

Warum Python für eine Aufgabe wählen, die traditionell von Enterprise-BI-Plattformen dominiert wird? Die Antwort liegt in seiner Flexibilität, seinem leistungsstarken Ökosystem und seiner Fähigkeit, den gesamten Datenlebenszyklus zu vereinheitlichen.

Warum Python?

• Eine einheitliche Sprache: Sie können Python für Datenextraktion (ETL), Transformation, Laden, Orchestrierung, Analyse, maschinelles Lernen und API-Entwicklung verwenden. Dies reduziert die Komplexität und die Notwendigkeit, zwischen verschiedenen Sprachen und Tools hin- und herzuschalten.
• Umfangreiches Bibliotheksökosystem: Python verfügt über ausgereifte, praxiserprobte Bibliotheken für jeden Schritt des Prozesses, von der Datenmanipulation (Pandas, Dask) über die Datenbankinteraktion (SQLAlchemy) bis hin zum Workflow-Management (Airflow, Prefect).
• Herstellerunabhängig: Python ist Open Source und verbindet sich mit allem. Egal, ob Ihre Daten in einer PostgreSQL-Datenbank, einem Snowflake-Warehouse, einem S3-Data-Lake oder einem Google Sheet gespeichert sind, es gibt eine Python-Bibliothek, um darauf zuzugreifen.
• Skalierbarkeit: Python-Lösungen können von einem einfachen Skript, das auf einem Laptop läuft, bis zu einem verteilten System skaliert werden, das Petabyte an Daten auf einem Cloud-Cluster mit Tools wie Dask oder Spark (über PySpark) verarbeitet.

Kern-Python-Bibliotheken für den Data-Warehouse-Stack

Eine typische Python-basierte Data-Warehousing-Lösung ist kein einzelnes Produkt, sondern eine kuratierte Sammlung leistungsstarker Bibliotheken. Hier sind die wichtigsten:

Für ETL/ELT (Extract, Transform, Load)

• Pandas: Der De-facto-Standard für die In-Memory-Datenmanipulation in Python. Perfekt für die Verarbeitung kleiner bis mittelgroßer Datensätze (bis zu einigen Gigabyte). Sein DataFrame-Objekt ist intuitiv und leistungsstark für die Bereinigung, Transformation und Analyse von Daten.
• Dask: Eine parallele Computing-Bibliothek, die Ihre Python-Analysen skaliert. Dask bietet ein paralleles DataFrame-Objekt, das die Pandas-API nachahmt, aber auf Datensätzen arbeiten kann, die größer als der Speicher sind, indem es sie in Chunks aufteilt und parallel auf mehreren Kernen oder Maschinen verarbeitet.
• SQLAlchemy: Das führende SQL-Toolkit und der Object Relational Mapper (ORM) für Python. Es bietet eine konsistente, High-Level-API für die Verbindung zu praktisch jeder SQL-Datenbank, von SQLite bis hin zu Enterprise-Grade-Warehouses wie BigQuery oder Redshift.
• Workflow-Orchestratoren (Airflow, Prefect, Dagster): Ein Data Warehouse wird nicht auf einem einzigen Skript aufgebaut. Es ist eine Reihe von abhängigen Aufgaben (Extrahieren aus A, Transformieren von B, Laden in C, Überprüfen von D). Mit Orchestratoren können Sie diese Workflows als Directed Acyclic Graphs (DAGs) definieren, planen, überwachen und mit Robustheit wiederholen.

Für Datenspeicherung und -verarbeitung

• Cloud DWH Connectors: Bibliotheken wie snowflake-connector-python, google-cloud-bigquery und psycopg2 (für Redshift und PostgreSQL) ermöglichen eine nahtlose Interaktion mit wichtigen Cloud-Data-Warehouses.
• PyArrow: Eine wichtige Bibliothek für die Arbeit mit spaltenorientierten Datenformaten. Sie bietet ein standardisiertes In-Memory-Format und ermöglicht eine High-Speed-Datenübertragung zwischen Systemen. Sie ist die Engine für effiziente Interaktionen mit Formaten wie Parquet.
• Moderne Lakehouse-Bibliotheken: Für fortgeschrittene Setups ermöglichen Bibliotheken wie deltalake, py-iceberg und - für Spark-Benutzer - die native Unterstützung dieser Formate durch PySpark den Aufbau zuverlässiger, transaktionaler Data Lakes mit Python, die als Grundlage eines Warehouse dienen.

Teil 3: Entwerfen eines OLAP-Systems mit Python

Kommen wir nun von der Theorie zur Praxis. Hier ist eine Schritt-für-Schritt-Anleitung zum Entwerfen Ihres Analysesystems.

Schritt 1: Datenmodellierung für Analysen

Die Grundlage jedes guten OLAP-Systems ist sein Datenmodell. Ziel ist es, Daten für schnelle, intuitive Abfragen zu strukturieren. Die gebräuchlichsten und effektivsten Modelle sind das Sternschema und seine Variante, das Snowflake-Schema.

Sternschema vs. Snowflake-Schema

Das Sternschema ist die am weitesten verbreitete Struktur für Data Warehouses. Es besteht aus:

• Einer zentralen Faktentabelle: Enthält die Measures (die Zahlen, die Sie analysieren möchten) und Fremdschlüssel zu den Dimensionstabellen.
• Mehreren Dimensionstabellen: Jede Dimensionstabelle ist über einen einzigen Schlüssel mit der Faktentabelle verbunden und enthält beschreibende Attribute. Diese Tabellen sind zur Vereinfachung und Beschleunigung stark denormalisiert.

Beispiel: Eine `FactSales`-Tabelle mit Spalten wie `DateKey`, `ProductKey`, `StoreKey`, `QuantitySold` und `TotalRevenue`. Sie wäre von `DimDate`-, `DimProduct`- und `DimStore`-Tabellen umgeben.

Das Snowflake-Schema ist eine Erweiterung des Sternschemas, bei dem die Dimensionstabellen in mehrere zusammengehörige Tabellen normalisiert werden. Beispielsweise könnte die Tabelle `DimProduct` in die Tabellen `DimProduct`, `DimBrand` und `DimCategory` unterteilt werden.

Empfehlung: Beginnen Sie mit einem Sternschema. Die Abfragen sind einfacher (weniger Joins), und moderne spaltenorientierte Datenbanken sind so effizient bei der Handhabung breiter, denormalisierter Tabellen, dass die Speichervorteile von Snowflake-Schemas oft vernachlässigbar sind im Vergleich zu den Leistungskosten zusätzlicher Joins.

Schritt 2: Erstellen der ETL/ELT-Pipeline in Python

Der ETL-Prozess ist das Rückgrat, das Ihr Data Warehouse speist. Er umfasst das Extrahieren von Daten aus Quellsystemen, das Transformieren in ein sauberes und konsistentes Format und das Laden in Ihr Analysemodell.

Lassen Sie uns dies anhand eines einfachen Python-Skripts mit Pandas veranschaulichen. Stellen Sie sich vor, wir haben eine CSV-Quelldatei mit Rohbestellungen.

# Ein vereinfachtes ETL-Beispiel mit Python und Pandas

import pandas as pd

# --- EXTRAHIEREN ---
print("Extrahieren von Rohbestelldaten...")
source_df = pd.read_csv('raw_orders.csv')

# --- TRANSFORMIEREN ---
print("Transformieren von Daten...")

# 1. Daten bereinigen
source_df['order_date'] = pd.to_datetime(source_df['order_date'])
source_df['product_price'] = pd.to_numeric(source_df['product_price'], errors='coerce')
source_df.dropna(inplace=True)

# 2. Daten anreichern - Erstellen einer separaten Datumsdimension
dim_date = pd.DataFrame({
    'DateKey': source_df['order_date'].dt.strftime('%Y%m%d').astype(int),
    'Date': source_df['order_date'].dt.date,
    'Year': source_df['order_date'].dt.year,
    'Quarter': source_df['order_date'].dt.quarter,
    'Month': source_df['order_date'].dt.month,
    'DayOfWeek': source_df['order_date'].dt.day_name()
}).drop_duplicates().reset_index(drop=True)

# 3. Erstellen einer Produktdimension
dim_product = source_df[['product_id', 'product_name', 'category']].copy()
dim_product.rename(columns={'product_id': 'ProductKey'}, inplace=True)
dim_product.drop_duplicates(inplace=True).reset_index(drop=True)

# 4. Erstellen der Faktentabelle
fact_sales = source_df.merge(dim_date, left_on=source_df['order_date'].dt.date, right_on='Date')\
                      .merge(dim_product, left_on='product_id', right_on='ProductKey')

fact_sales = fact_sales[['DateKey', 'ProductKey', 'order_id', 'quantity', 'product_price']]
fact_sales['TotalRevenue'] = fact_sales['quantity'] * fact_sales['product_price']
fact_sales.rename(columns={'order_id': 'OrderCount'}, inplace=True)

# Auf die gewünschte Granularität aggregieren
fact_sales = fact_sales.groupby(['DateKey', 'ProductKey']).agg(
    TotalRevenue=('TotalRevenue', 'sum'),
    TotalQuantity=('quantity', 'sum')
).reset_index()

# --- LADEN ---
print("Laden von Daten in den Zielspeicher...")
# In diesem Beispiel speichern wir in Parquet-Dateien, einem hocheffizienten spaltenorientierten Format
dim_date.to_parquet('warehouse/dim_date.parquet')
dim_product.to_parquet('warehouse/dim_product.parquet')
fact_sales.to_parquet('warehouse/fact_sales.parquet')

print("ETL-Prozess abgeschlossen!")

Dieses einfache Skript demonstriert die Kernlogik. In einem realen Szenario würden Sie diese Logik in Funktionen verpacken und ihre Ausführung mit einem Orchestrator wie Airflow verwalten.

Schritt 3: Auswählen und Implementieren der OLAP-Engine

Nachdem Ihre Daten modelliert und geladen wurden, benötigen Sie eine Engine, um die OLAP-Operationen durchzuführen. In der Python-Welt haben Sie mehrere leistungsstarke Optionen, die hauptsächlich dem ROLAP-Ansatz folgen.

Ansatz A: Das leichtgewichtige Kraftpaket - DuckDB

DuckDB ist eine In-Process-Analysedatenbank, die unglaublich schnell und einfach mit Python zu verwenden ist. Sie kann Pandas DataFrames oder Parquet-Dateien direkt mit SQL abfragen. Sie ist die perfekte Wahl für kleine bis mittelgroße OLAP-Systeme, Prototypen und die lokale Entwicklung.

Sie fungiert als hochleistungsfähige ROLAP-Engine. Sie schreiben Standard-SQL, und DuckDB führt sie mit extremer Geschwindigkeit über Ihre Datendateien aus.

import duckdb

# Verbinden mit einer In-Memory-Datenbank oder einer Datei
con = duckdb.connect(database=':memory:', read_only=False)

# Direkte Abfrage der Parquet-Dateien, die wir zuvor erstellt haben
# DuckDB versteht das Schema automatisch
result = con.execute("""
SELECT
    p.category,
    d.Year,
    SUM(f.TotalRevenue) AS AnnualRevenue
FROM 'warehouse/fact_sales.parquet' AS f
JOIN 'warehouse/dim_product.parquet' AS p ON f.ProductKey = p.ProductKey
JOIN 'warehouse/dim_date.parquet' AS d ON f.DateKey = d.DateKey
WHERE p.category = 'Electronics'
GROUP BY p.category, d.Year
ORDER BY d.Year;
""").fetchdf() # fetchdf() gibt ein Pandas DataFrame zurück

print(result)

Ansatz B: Die Cloud-Scale-Titanen - Snowflake, BigQuery, Redshift

Für groß angelegte Enterprise-Systeme ist ein Cloud-Data-Warehouse die Standardwahl. Python lässt sich nahtlos in diese Plattformen integrieren. Ihr ETL-Prozess würde Daten in das Cloud-DWH laden, und Ihre Python-Anwendung (z. B. ein BI-Dashboard oder ein Jupyter Notebook) würde es abfragen.

Die Logik bleibt die gleiche wie bei DuckDB, aber die Verbindung und die Skalierung sind anders.

import snowflake.connector

# Beispiel für die Verbindung zu Snowflake und die Ausführung einer Abfrage
conn = snowflake.connector.connect(
    user='your_user',
    password='your_password',
    account='your_account_identifier'
)

cursor = conn.cursor()

try:
    cursor.execute("USE WAREHOUSE MY_WH;")
    cursor.execute("USE DATABASE MY_DB;")
    cursor.execute("""
        SELECT category, YEAR(date), SUM(total_revenue)
        FROM fact_sales 
        JOIN dim_product ON ...
        JOIN dim_date ON ...
        GROUP BY 1, 2;
    """)
    # Ergebnisse nach Bedarf abrufen
    for row in cursor:
        print(row)
finally:
    cursor.close()
    conn.close()

Ansatz C: Die Echtzeitspezialisten - Apache Druid oder ClickHouse

Für Anwendungsfälle, die eine Abfragelatenz im Subsekundenbereich auf massiven Streaming-Datensätzen erfordern (wie z. B. Echtzeit-Benutzeranalysen), sind spezialisierte Datenbanken wie Druid oder ClickHouse eine ausgezeichnete Wahl. Sie sind spaltenorientierte Datenbanken, die für OLAP-Workloads entwickelt wurden. Python wird verwendet, um Daten in sie zu streamen und sie über ihre jeweiligen Client-Bibliotheken oder HTTP-APIs abzufragen.

Teil 4: Ein praktisches Beispiel - Aufbau eines Mini-OLAP-Systems

Lassen Sie uns diese Konzepte zu einem Mini-Projekt zusammenfassen: einem interaktiven Verkaufs-Dashboard. Dies demonstriert ein vollständiges, wenn auch vereinfachtes Python-basiertes OLAP-System.

Unser Stack:

• ETL: Python und Pandas
• Datenspeicherung: Parquet-Dateien
• OLAP Engine: DuckDB
• Dashboard: Streamlit (eine Open-Source-Python-Bibliothek zum Erstellen schöner, interaktiver Web-Apps für Data Science)

Führen Sie zunächst das ETL-Skript aus Teil 3 aus, um die Parquet-Dateien in einem `warehouse/`-Verzeichnis zu generieren.

Erstellen Sie als Nächstes die Dashboard-Anwendungsdatei `app.py`:

# app.py - Ein einfaches interaktives Verkaufs-Dashboard

import streamlit as st
import duckdb
import pandas as pd
import plotly.express as px

# --- Seitenkonfiguration ---
st.set_page_config(layout="wide", page_title="Global Sales Dashboard")
st.title("Interaktives Sales OLAP Dashboard")

# --- Verbinden mit DuckDB ---
# Dies fragt unsere Parquet-Dateien direkt ab
con = duckdb.connect(database=':memory:', read_only=True)

# --- Laden von Dimensionsdaten für Filter ---
@st.cache_data
def load_dimensions():
    products = con.execute("SELECT DISTINCT category FROM 'warehouse/dim_product.parquet'").fetchdf()
    years = con.execute("SELECT DISTINCT Year FROM 'warehouse/dim_date.parquet' ORDER BY Year").fetchdf()
    return products['category'].tolist(), years['Year'].tolist()

categories, years = load_dimensions()

# --- Seitenleiste für Filter (Slicing und Dicing!) ---
st.sidebar.header("OLAP-Filter")

selected_categories = st.sidebar.multiselect(
    'Produktkategorien auswählen',
    options=categories,
    default=categories
)

selected_year = st.sidebar.selectbox(
    'Jahr auswählen',
    options=years,
    index=len(years)-1 # Standardmäßig das letzte Jahr
)

# --- Erstellen der OLAP-Abfrage dynamisch ---
if not selected_categories:
    st.warning("Bitte wählen Sie mindestens eine Kategorie aus.")
    st.stop()

query = f"""
SELECT
    d.Month,
    d.MonthName, -- Unter der Annahme, dass MonthName in DimDate vorhanden ist
    p.category,
    SUM(f.TotalRevenue) AS Revenue
FROM 'warehouse/fact_sales.parquet' AS f
JOIN 'warehouse/dim_product.parquet' AS p ON f.ProductKey = p.ProductKey
JOIN 'warehouse/dim_date.parquet' AS d ON f.DateKey = d.DateKey
WHERE d.Year = {selected_year}
  AND p.category IN ({str(selected_categories)[1:-1]})
GROUP BY d.Month, d.MonthName, p.category
ORDER BY d.Month;
"""

# --- Abfrage ausführen und Ergebnisse anzeigen ---
@st.cache_data
def run_query(_query):
    return con.execute(_query).fetchdf()

results_df = run_query(query)

if results_df.empty:
    st.info(f"Keine Daten für die ausgewählten Filter im Jahr {selected_year} gefunden.")
else:
    # --- Haupt-Dashboard-Visualisierungen ---
    col1, col2 = st.columns(2)

    with col1:
        st.subheader(f"Monatlicher Umsatz für {selected_year}")
        fig = px.line(
            results_df,
            x='MonthName',
            y='Revenue',
            color='category',
            title='Monatlicher Umsatz nach Kategorie'
        )
        st.plotly_chart(fig, use_container_width=True)

    with col2:
        st.subheader("Umsatz nach Kategorie")
        category_summary = results_df.groupby('category')['Revenue'].sum().reset_index()
        fig_pie = px.pie(
            category_summary,
            names='category',
            values='Revenue',
            title='Gesamtumsatzanteil nach Kategorie'
        )
        st.plotly_chart(fig_pie, use_container_width=True)

    st.subheader("Detaillierte Daten")
    st.dataframe(results_df)

Um dies auszuführen, speichern Sie den Code als `app.py` und führen Sie `streamlit run app.py` in Ihrem Terminal aus. Dadurch wird ein Webbrowser mit Ihrem interaktiven Dashboard gestartet. Die Filter in der Seitenleiste ermöglichen es Benutzern, OLAP-'Slicing'- und 'Dicing'-Operationen durchzuführen, und das Dashboard wird in Echtzeit aktualisiert, indem DuckDB erneut abgefragt wird.

Teil 5: Erweiterte Themen und Best Practices

Wenn Sie von einem Mini-Projekt zu einem Produktionssystem übergehen, sollten Sie diese erweiterten Themen berücksichtigen.

Skalierbarkeit und Leistung

• Dask für großes ETL verwenden: Wenn Ihre Quelldaten den RAM Ihres Rechners überschreiten, ersetzen Sie Pandas in Ihren ETL-Skripten durch Dask. Die API ist sehr ähnlich, aber Dask übernimmt die Out-of-Core- und Parallelverarbeitung.
• Spaltenorientierte Speicherung ist der Schlüssel: Speichern Sie Ihre Warehouse-Daten immer in einem spaltenorientierten Format wie Apache Parquet oder ORC. Dies beschleunigt analytische Abfragen erheblich, da in der Regel nur wenige Spalten aus einer breiten Tabelle gelesen werden müssen.
• Partitionierung: Wenn Sie Daten in einem Data Lake (wie S3 oder einem lokalen Dateisystem) speichern, partitionieren Sie Ihre Daten in Ordner basierend auf einer häufig gefilterten Dimension, wie z. B. Datum. Zum Beispiel: `warehouse/fact_sales/year=2023/month=12/`. Dadurch können Abfrage-Engines das Lesen irrelevanter Daten überspringen, ein Prozess, der als "Partition Pruning" bezeichnet wird.

Die semantische Schicht

Wenn Ihr System wächst, werden Sie feststellen, dass Geschäftslogik (wie die Definition von 'Aktiver Benutzer' oder 'Bruttomarge') in mehreren Abfragen und Dashboards wiederholt wird. Eine semantische Schicht löst dieses Problem, indem sie eine zentralisierte, konsistente Definition Ihrer Geschäftskennzahlen und -dimensionen bereitstellt. Tools wie dbt (Data Build Tool) sind hierfür hervorragend geeignet. Obwohl dbt selbst kein Python-Tool ist, lässt es sich perfekt in einen von Python orchestrierten Workflow integrieren. Sie verwenden dbt, um Ihr Sternschema zu modellieren und Metriken zu definieren, und dann kann Python verwendet werden, um dbt-Ausführungen zu orchestrieren und erweiterte Analysen auf den resultierenden sauberen Tabellen durchzuführen.

Daten-Governance und -Qualität

Ein Warehouse ist nur so gut wie die Daten, die darin enthalten sind. Integrieren Sie Datenqualitätsprüfungen direkt in Ihre Python-ETL-Pipelines. Mit Bibliotheken wie Great Expectations können Sie 'Erwartungen' an Ihre Daten definieren (z. B. `customer_id` darf niemals null sein, `revenue` muss zwischen 0 und 1.000.000 liegen). Ihr ETL-Job kann dann fehlschlagen oder Sie benachrichtigen, wenn eingehende Daten diese Verträge verletzen, wodurch verhindert wird, dass fehlerhafte Daten Ihr Warehouse beschädigen.

Fazit: Die Leistungsfähigkeit eines Code-First-Ansatzes

Python hat die Landschaft von Data Warehousing und Business Intelligence grundlegend verändert. Es bietet ein flexibles, leistungsstarkes und herstellerneutrales Toolkit für den Aufbau ausgefeilter Analysesysteme von Grund auf. Durch die Kombination von erstklassigen Bibliotheken wie Pandas, Dask, SQLAlchemy und DuckDB können Sie ein komplettes OLAP-System erstellen, das sowohl skalierbar als auch wartbar ist.

Die Reise beginnt mit einem soliden Verständnis der Datenmodellierungsprinzipien wie dem Sternschema. Von dort aus können Sie robuste ETL-Pipelines aufbauen, um Ihre Daten zu formen, die richtige Abfrage-Engine für Ihre Skalierung auswählen und sogar interaktive Analyseanwendungen erstellen. Dieser Code-First-Ansatz, oft ein Kernprinzip des 'Modern Data Stack', legt die Macht der Analysen direkt in die Hände von Entwicklern und Datenteams und ermöglicht es ihnen, Systeme zu entwickeln, die perfekt auf die Bedürfnisse ihrer Organisation zugeschnitten sind.